home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group92c.txt
/
000082_icon-group-sender _Thu Nov 12 22:19:21 1992.msg
< prev
next >
Wrap
Internet Message Format
|
1993-01-04
|
2KB
Received: by cheltenham.cs.arizona.edu; Fri, 13 Nov 1992 05:29:29 MST
Date: Thu, 12 Nov 1992 22:19:21 MST
From: "President Clinton Jeffery" <cjeffery>
Message-Id: <199211130519.AA22161@chuckwalla.cs.arizona.edu>
To: isidev!nowlin@uunet.uu.net
Cc: icon-group
In-Reply-To: isidev!nowlin@uunet.uu.net's message of Thu, 12 Nov 92 18:36:19 -0500 <9211122336.AA23580@relay2.UU.NET>
Subject: Re rationale for sortf()
Status: R
Errors-To: icon-group-errors@cs.arizona.edu
Jerry Nowlin writes:
> You can define tables with field names as key and the record index as value
> and just use that in place of field name arguments to sortf(). When you
> change record definitions you would have to change tables values. This
> won't help with Idol unfortunately. Maybe Idol could put extra fields at
> the end of records to avoid obscuring known index values?
An interesting thought. There is no reason the two "extra fields" could not
be put at the back. But current default behavior notwithstanding, objects
are not supposed to be transparent and allow any old function to access
their internal fields; a sortf() that would be technically correct for Idol
would call a procedure (method, really) to access the key, and there are real
technical reasons why sortf() doesn't call back out to an Icon procedure (or
Idol method) in the present implementation -- none of Icon's built-in
functions do that, in fact. Writing a built-in Icon function that calls
procedures is our user-grailquest for the week; in the meantime sorters of
lists of objects would do well to consider adapting Bob Alexander's elegant
isort procedure from the Icon program library.